home *** CD-ROM | disk | FTP | other *** search
/ Celestin Apprentice 5 / Apprentice-Release5.iso / Source Code / C / Frameworks / TransSkel 3.24 / Documents / Misc / movable-modal-wdef-zen.txt
Text File  |  1996-01-17  |  7KB  |  127 lines
  1.  
  2. Zen and the Art of the Movable-Modal Dialog Window
  3.  
  4. **********
  5.  
  6. A developer asks:
  7.  
  8. "I handle dragging in my ModalDialog filterProc by detecting mouse clicks,
  9. checking FindWindow=inDrag+whichWindow=myDialog, and then DragWindow.  I let
  10. ModalDialog() field the update events generated when I am dragging the dialog
  11. from partially-offscreen to totally-onscreen.  Unfortunately, the
  12. update-response draws a zoom box.  If I move the initial zoomboxless window to
  13. the point where half an imaginary zoombox would be offscreen, and then drag
  14. back, sure enough--I get the half zoombox drawn in.
  15.  
  16. Am I doing something wrong with my resource numbering?
  17.  
  18. I notice that this behavior also happens if I renumber it to WDEF#0, letting it
  19. become responsible for drawing all my window types. (I set procID to 5 in this
  20. case, of course.)"
  21.  
  22. **********
  23.  
  24. Before I explain what's wrong, I have to make something perfectly clear.  The
  25. movable-modal dialog should NOT be used in the call to _ModalDialog.  (Note:
  26. Along with the information in this release note, you should check Human
  27. Interface Note #4 for a discussion of the important interface issued involved
  28. with this new window type.)  There are two technical reasons for this.  First,
  29. and most importantly, is that calling _ModalDialog prevents switching to take
  30. place under MultiFinder.  This is opposed to the design of the new window,
  31. since it is designed to allow switching.  Second, a dialog filter procedure
  32. does not facilitate the proper usage of the new window.  Since the new window
  33. can be moved, the window underneath needs to be updated.  Updating windows in
  34. the background is not easily accomplished from a dialog filter.  Furthermore,
  35. there are all the other events that need to be handled, such as
  36. activate/deactivate, suspend/resume, drag, zoom, etc.  This is all a
  37. duplication of the standard event loop.
  38.  
  39. The movable-modal dialog handler should go through the normal event loop.
  40. Before you object and say this isn't easy, I have tried to point out how
  41. difficult it is trying to use a dialog filter, and you can get more information
  42. about this in Technical Note #203, Don't Abuse the Managers.  It is also
  43. incorrect to call _ModalDialog since this prevents switching.  Now you may be
  44. thinking that you can use a modeless dialog.  This also has a nasty problem.
  45. In the course of handling a modeless dialog, the application uses
  46. _IsDialogEvent and _DialogSelect.
  47.  
  48. _IsDialogEvent always returns true for any events (except for mouse down,
  49. activate and update) when a dialog is the frontmost window.  (Note that even if
  50. you are doing things correctly, there is a bug in _IsDialogEvent which causes
  51. it to fail if there isn't a window, i.e., FrontWind = NIL.)  Applications that
  52. are MultiFinderAware (bit in 'SIZE' resource) need to make a fake activate
  53. event to pass to _DialogSelect if their frontmost window is a modeless dialog
  54. when they get a suspend or resume event.  Since _IsDialogEvent does this, the
  55. application has to check for osEvents before calling _IsDialogEvent, or ignore
  56. the result from _IsDialogEvent.  Note that if the event gets passed to
  57. _DialogSelect, it handles the event as if it is a nullEvt (it does that with
  58. events it does not recognize), which is harmless, but if the application misses
  59. it, there could be a problem.
  60.  
  61. Handling a movable-modal dialog is just like any other window.  There are
  62. really only two differences.  If the front window is the movable-modal, then
  63. you ignore any click outside the window.  Also ignore menu command keys.  The
  64. latter is currently a subject of discussion with the Human Interface group.
  65. I've found that it's very difficult to handle the menu if the window is modal.
  66. The biggest problem is what items would be enabled?  Should a desk accessory be
  67. allowed to be opened?  Maybe the solution is to disable ALL of the menu items.
  68. That's up to the Human Interface group to come up with some guidelines.
  69.  
  70. I've found that adding the movable-modal dialog support to my standard event
  71. loop only changed a couple lines of code.  I'm working on a example that
  72. demonstrates how to use this new window type correctly and that covers both the
  73. technical and user interface issues.  It will be published from DTS as soon as
  74. it is finished.
  75.  
  76. Another point that should be covered is this 'WDEF' is NOT a replacement for
  77. the standard system 'WDEF'.  The 'WDEF' that supports the new window type will
  78. be built into System 7.0.  Until then, applications can include a modified
  79. version of the current 'WDEF'.  This modified version should only be used to
  80. obtain the movable-modal window type.  The 'WDEF' resource ID is 128, therefore
  81. the ProcID should be (16 * 128) + 5 = 2053.  To support zooming, you add 8.  Do
  82. not use this 'WDEF' as ResID = 0.  This would override the standard 'WDEF', and
  83. things are changing.  System Software after 6.0.4 has a very slight change in
  84. the window's drop shadow on a multibit depth Macintosh.
  85.  
  86. Furthermore, the window may change slightly in look and behavior for System
  87. 7.0.  The current version of the movable-modal draws a gray frame when the
  88. window is deactivated.  This was done because the application can be switched
  89. into the background and the movable-modal should not appear as a modal dialog.
  90. You should use the standard 'WDEF' while running System 7.0.  In this case, the
  91. ProcID is (16 * 0) + 5 = 5.  This is a little tricky and I'll leave the
  92. explanation to my sample code.  I promise I'll release this very soon (I just
  93. got the 'WDEF' finished).
  94.  
  95. "What about that bug we saw?"
  96.  
  97. The problem reported in the first release of the 'WDEF' has been found and
  98. solved.  The real problem is not in the 'WDEF', but that it is being used
  99. incorrectly.  Namely, this new window should not be used with _ModalDialog.
  100. The problem is a conflict with the Window Manager and MultiFinder's patch to
  101. _ModalDialog.  There is a field in the Window Record used by the 'WDEF'.
  102. Originally this field was named "spareFlag."  When zoomable windows were
  103. invented, this flag was used to determine if the window supported the zoom box.
  104. Since that time, this same field has become known as "wZoom."
  105.  
  106. MultiFinder uses this field in its patch to _ModalDialog which prevents
  107. switching to another application.  Hitherto unknown, this conflict wasn't a
  108. problem because modal windows had no title bars.  I've made a change in the
  109. 'WDEF' to ignore this field of the window record.  That solves the conflict of
  110. MultiFinder's patch to _ModalDialog.
  111.  
  112. The fixed version is a ResEdit file created:  Mar 1, 1990
  113.  
  114. You can also verify you have the right WDEF resource by looking at the first
  115. few bytes.
  116.  
  117. $600A0000    This is a JMP instruction
  118. $57444546    This is ASCII for "WDEF"
  119. $0080        This is the ResID=128
  120. $0065        This is the version number 1.01
  121.  
  122. Finally, I've named this 'WDEF' resource "movable-modal 1.01."
  123.  
  124.  
  125. Jim Reekes E.O., Macintosh Developer Technical Support
  126. Thursday, March 1, 1990   5:08 PM
  127.